Visual Studio provides an intuitive interface for debugging both
managed and native applications. The Visual Studio debugger is a
separate component within the Visual Studio integrated development
environment (IDE). Visual Studio 2010 introduces many new debugging
features, such as the ability to create and save managed dumps. In
addition, you can now use Visual Studio to perform managed post-mortem
analysis on a dump.
You can perform real-time debugging of a running application. This is considered live debugging, which you can start in several different ways:
-
You can start debugging from an active project. Open the Visual
Studio project for your managed application. This should be a runnable
application, such as a Console or Windows Forms application. Select
Debug from the menu, and then select Start Debugging. (The shortcut key
is F5.) Assuming that your program compiles successfully, the
application will start with the debugger attached.
-
You can attach the debugger to a running application by using Visual
Studio. From the menu, select Debugging, and then select Attach To
Process. The dialog box shown in the following image appears. Select the
application you want to debug from the list, and then click the Attach
button. If you have a corresponding project available, you might want to
open it first. This would help with source-level debugging.
-
The last option is known as Just-In-Time debugging.
When an application crashes, a dialog box appears that presents you
with several choices (see the following image). One of the options is to
attach the debugger and begin debugging the application in a Visual
Studio session. From the crash dialog box, select the Continue button to
begin Just-In-Time debugging. Visual Studio installs itself as the
default Just-In-Time debugger at installation.
Most of the user interface for debugging, such as the various
debugging windows, is not available for use unless the application is
running but interrupted. It is hard to debug a moving target. However,
there are a variety of techniques to interrupt an application, most
normally breakpoints. You can insert a breakpoint into a running
application from the Debug menu in Visual Studio.
There are several types of breakpoints:
-
Location
. This sets a breakpoint on a specific source statement.
-
Condition
. This honors the breakpoint when a Boolean condition is true. For example, you can honor the breakpoint if a variable contains a specific value.
-
Hit Count
. This sets a breakpoint on a specific instance, such as every third instance or when a variable exceeds a certain value.
-
Filter
. This type filters a breakpoint on a thread, process,
or machine. This is useful when there are several threads executing
through the same source code. In this circumstance, it might be useful
to break on a specific thread.
-
When Hit
. This executes a macro or displays a trace message when the breakpoint is hit. A When Hit breakpoint is also known as a Tracepoint
and looks different than other breakpoints: It appears as a diamond,
not as a red circle. By default, when they are hit, When Hit breakpoints
do not break! When one of these breakpoints is hit, the trace is
displayed or the macro is executed. You can choose to break at the
breakpoint by selecting that option in the Tracepoint dialog box. If
this option is chosen, the breakpoint changes to the common red circle
for breakpoints and execution is interrupted when the breakpoint is hit.
Most developers set a location breakpoint by using the F9 function
key. Simply place the insertion point at the target location in your
source code and click F9. The F9 shortcut key acts as a toggle to turn a
breakpoint on or off. You can also convert an existing breakpoint to another
type by using the context menu. Right-click the breakpoint in the
source window or in the Breakpoints window to change the type, as shown
in the following image.
Performing Post-Mortem Analysis
Post-mortem analysis involves debugging an application after
execution has completed—a task that is most often accomplished with
dumps. Managed debugging of dumps is an important new feature of Visual
Studio 2010 and includes creating and opening managed dumps, which is
extremely important in a production environment in which live debugging
is not an option. Instead of debugging, you can create a dump of the
application.
To create a dump, you first interrupt the running application. One
method is to choose Debug from the menu and then select Break All. After
interrupting the application, choose Save Dump As from the Debug menu.
The Save Dump As dialog box appears. Enter the name, and select the type
of dump you want to create. You can create dumps both with or without
heap information. The default is mini dumps with heap information. To
create dumps of applications already running, start with Tools | Attach
To Process in Visual Studio, which might include identifying a remote
machine. You can then create the dump.
You can also open managed dumps in Visual Studio. If possible, open
the related project first. The dump file does not have to be created in
Visual Studio—it might have been created from another application, such
as Windows Task Manager, WinDbg, or ADPlus. After opening a dump, Visual
Studio displays the Minidump File Summary, as shown in the next image.
This window presents summary information pertaining to the dump,
including when the dump was created, the list of loaded modules, and the
originating operating system. To start debugging with the dump, select
the Debug With Mixed or Debug With Native Only button (the green
triangles in the Actions section). You can then begin your analysis by
using the various debug windows.
